[PATCH 18/44] net: mana: Refactor RX buffer allocation code to prepare for various MTU
Move out common buffer allocation code from mana_process_rx_cqe() and
mana_alloc_rx_wqe() to helper functions.
Refactor related variables so they can be changed in one place, and buffer
sizes are in sync.
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com> Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit a2917b23497e4205db32271e4e06e142a9f8a6aa) Signed-off-by: Bastian Blank <waldi@debian.org>
Gbp-Pq: Topic features/all/ethernet-microsoft
Gbp-Pq: Name 0018-net-mana-Refactor-RX-buffer-allocation-code-to-prepa.patch
Remove pci_clear_master to simplify the code,
the bus-mastering is also cleared in do_pci_disable_device,
like this:
./drivers/pci/pci.c:2197
static void do_pci_disable_device(struct pci_dev *dev)
{
u16 pci_command;
pcibios_disable_device(dev);
}.
And dev->is_busmaster is set to 0 in pci_disable_device.
Signed-off-by: Cai Huoqing <cai.huoqing@linux.dev> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 2d59af8307526f2829fdec9c5c5898a857d55180) Signed-off-by: Bastian Blank <waldi@debian.org>
Gbp-Pq: Topic features/all/ethernet-microsoft
Gbp-Pq: Name 0016-net-mana-Remove-redundant-pci_clear_master.patch
After calling irq_set_affinity_and_hint(), the cpumask pointer is
saved in desc->affinity_hint, and will be used later when reading
/proc/irq/<num>/affinity_hint. So the cpumask variable needs to be
persistent. Otherwise, we are accessing freed memory when reading
the affinity_hint file.
Also, need to clear affinity_hint before free_irq(), otherwise there
is a one-time warning and stack trace during module unloading:
[PATCH 13/44] net: mana: Fix return type of mana_start_xmit()
The ndo_start_xmit field in net_device_ops is expected to be of type
netdev_tx_t (*ndo_start_xmit)(struct sk_buff *skb, struct net_device *dev).
The mismatched return type breaks forward edge kCFI since the underlying
function definition does not match the function hook definition. A new
warning in clang will catch this at compile time:
drivers/net/ethernet/microsoft/mana/mana_en.c:382:21: error: incompatible function pointer types initializing 'netdev_tx_t (*)(struct sk_buff *, struct net_device *)' (aka 'enum netdev_tx (*)(struct sk_buff *, struct net_device *)') with an expression of type 'int (struct sk_buff *, struct net_device *)' [-Werror,-Wincompatible-function-pointer-types-strict]
.ndo_start_xmit = mana_start_xmit,
^~~~~~~~~~~~~~~
1 error generated.
The return type of mana_start_xmit should be changed from int to
netdev_tx_t.
Ajay Sharma [Thu, 3 Nov 2022 19:16:29 +0000 (12:16 -0700)]
[PATCH 12/44] net: mana: Define data structures for protection domain and memory registration
The MANA hardware support protection domain and memory registration for use
in RDMA environment. Add those definitions and expose them for use by the
RDMA driver.
Signed-off-by: Ajay Sharma <sharmaajay@microsoft.com> Signed-off-by: Long Li <longli@microsoft.com> Link: https://lore.kernel.org/r/1667502990-2559-12-git-send-email-longli@linuxonhyperv.com Reviewed-by: Dexuan Cui <decui@microsoft.com> Acked-by: Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
(cherry picked from commit 28c66cfa45388af1126985d1114e0ed762eb2abd) Signed-off-by: Bastian Blank <waldi@debian.org>
Gbp-Pq: Topic features/all/ethernet-microsoft
Gbp-Pq: Name 0012-net-mana-Define-data-structures-for-protection-domai.patch
Ajay Sharma [Thu, 3 Nov 2022 19:16:27 +0000 (12:16 -0700)]
[PATCH 11/44] net: mana: Define and process GDMA response code GDMA_STATUS_MORE_ENTRIES
When doing memory registration, the PF may respond with
GDMA_STATUS_MORE_ENTRIES to indicate a follow request is needed. This is
not an error and should be processed as expected.
Signed-off-by: Ajay Sharma <sharmaajay@microsoft.com> Reviewed-by: Dexuan Cui <decui@microsoft.com> Signed-off-by: Long Li <longli@microsoft.com> Link: https://lore.kernel.org/r/1667502990-2559-10-git-send-email-longli@linuxonhyperv.com Acked-by: Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
(cherry picked from commit de372f2a9ca7ada2698ecac7df8f02407cd98fa0) Signed-off-by: Bastian Blank <waldi@debian.org>
Gbp-Pq: Topic features/all/ethernet-microsoft
Gbp-Pq: Name 0011-net-mana-Define-and-process-GDMA-response-code-GDMA_.patch
Long Li [Thu, 3 Nov 2022 19:16:26 +0000 (12:16 -0700)]
[PATCH 10/44] net: mana: Define max values for SGL entries
The number of maximum SGl entries should be computed from the maximum
WQE size for the intended queue type and the corresponding OOB data
size. This guarantees the hardware queue can successfully queue requests
up to the queue depth exposed to the upper layer.
Reviewed-by: Dexuan Cui <decui@microsoft.com> Signed-off-by: Long Li <longli@microsoft.com> Link: https://lore.kernel.org/r/1667502990-2559-9-git-send-email-longli@linuxonhyperv.com Acked-by: Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
(cherry picked from commit aa56549792fb348892fbbae67f6f0c71bb750b65) Signed-off-by: Bastian Blank <waldi@debian.org>
Gbp-Pq: Topic features/all/ethernet-microsoft
Gbp-Pq: Name 0010-net-mana-Define-max-values-for-SGL-entries.patch
Long Li [Thu, 3 Nov 2022 19:16:23 +0000 (12:16 -0700)]
[PATCH 07/44] net: mana: Export Work Queue functions for use by RDMA driver
RDMA device may need to create Ethernet device queues for use by Queue
Pair type RAW. This allows a user-mode context accesses Ethernet hardware
queues. Export the supporting functions for use by the RDMA driver.
Reviewed-by: Dexuan Cui <decui@microsoft.com> Signed-off-by: Long Li <longli@microsoft.com> Link: https://lore.kernel.org/r/1667502990-2559-6-git-send-email-longli@linuxonhyperv.com Acked-by: Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
(cherry picked from commit 4c0ff7a106e16ab63e0b597557255c012f179578) Signed-off-by: Bastian Blank <waldi@debian.org>
Gbp-Pq: Topic features/all/ethernet-microsoft
Gbp-Pq: Name 0007-net-mana-Export-Work-Queue-functions-for-use-by-RDMA.patch
Long Li [Thu, 3 Nov 2022 19:16:21 +0000 (12:16 -0700)]
[PATCH 05/44] net: mana: Handle vport sharing between devices
For outgoing packets, the PF requires the VF to configure the vport with
corresponding protection domain and doorbell ID for the kernel or user
context. The vport can't be shared between different contexts.
Implement the logic to exclusively take over the vport by either the
Ethernet device or RDMA device.
Reviewed-by: Dexuan Cui <decui@microsoft.com> Signed-off-by: Long Li <longli@microsoft.com> Link: https://lore.kernel.org/r/1667502990-2559-4-git-send-email-longli@linuxonhyperv.com Acked-by: Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
(cherry picked from commit b5c1c9855be3b5b978fde975a63df3cabc273faa) Signed-off-by: Bastian Blank <waldi@debian.org>
Gbp-Pq: Topic features/all/ethernet-microsoft
Gbp-Pq: Name 0005-net-mana-Handle-vport-sharing-between-devices.patch
Long Li [Thu, 3 Nov 2022 19:16:20 +0000 (12:16 -0700)]
[PATCH 04/44] net: mana: Record the physical address for doorbell page region
For supporting RDMA device with multiple user contexts with their
individual doorbell pages, record the start address of doorbell page
region for use by the RDMA driver to allocate user context doorbell IDs.
Reviewed-by: Dexuan Cui <decui@microsoft.com> Signed-off-by: Long Li <longli@microsoft.com> Link: https://lore.kernel.org/r/1667502990-2559-3-git-send-email-longli@linuxonhyperv.com Acked-by: Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
(cherry picked from commit f3dc096246091048677c45cfc0e24ad512927b52) Signed-off-by: Bastian Blank <waldi@debian.org>
Gbp-Pq: Topic features/all/ethernet-microsoft
Gbp-Pq: Name 0004-net-mana-Record-the-physical-address-for-doorbell-pa.patch
Long Li [Thu, 3 Nov 2022 19:16:19 +0000 (12:16 -0700)]
[PATCH 03/44] net: mana: Add support for auxiliary device
In preparation for supporting MANA RDMA driver, add support for auxiliary
device in the Ethernet driver. The RDMA device is modeled as an auxiliary
device to the Ethernet device.
Reviewed-by: Dexuan Cui <decui@microsoft.com> Signed-off-by: Long Li <longli@microsoft.com> Link: https://lore.kernel.org/r/1667502990-2559-2-git-send-email-longli@linuxonhyperv.com Acked-by: Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
(cherry picked from commit a69839d4327d053b18d8e1b0e7ddeee78db78f4f) Signed-off-by: Bastian Blank <waldi@debian.org>
Gbp-Pq: Topic features/all/ethernet-microsoft
Gbp-Pq: Name 0003-net-mana-Add-support-for-auxiliary-device.patch
Saurabh Sengar [Tue, 1 Nov 2022 06:06:01 +0000 (23:06 -0700)]
[PATCH 02/44] net: mana: Assign interrupts to CPUs based on NUMA nodes
In large VMs with multiple NUMA nodes, network performance is usually
best if network interrupts are all assigned to the same virtual NUMA
node. This patch assigns online CPU according to a numa aware policy,
local cpus are returned first, followed by non-local ones, then it wraps
around.
[PATCH 01/44] net: Remove the obsolte u64_stats_fetch_*_irq() users (drivers).
Now that the 32bit UP oddity is gone and 32bit uses always a sequence
count, there is no need for the fetch_irq() variants anymore.
Convert to the regular interface.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit 068c38ad88ccb09e5e966d4db5cedab0e02b3b95) Signed-off-by: Bastian Blank <waldi@debian.org>
Gbp-Pq: Topic features/all/ethernet-microsoft
Gbp-Pq: Name 0001-net-Remove-the-obsolte-u64_stats_fetch_-_irq-users-d.patch
jevents.py enumerates files and outputs the corresponding C structs in
the order they are found. This makes it sensitive to directory
ordering, so that the perf executable is not reproducible.
To avoid this, sort the entries returned by os.scandir() before
processing them.
References: https://tests.reproducible-builds.org/debian/dbdtxt/bullseye/i386/linux_4.19.37-6.diffoscope.txt.gz Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name tools-perf-pmu-events-fix-reproducibility.patch
Calls to cpufreq_cpu_exists(cpu) were converted to
cpupower_is_cpu_online(cpu) when libcpupower was introduced and the
former function was deleted. However, cpupower_is_cpu_online() does
not distinguish physically absent and offline CPUs, and does not set
errno.
cpufreq-set has already been fixed (commit c25badc9ceb6).
In cpufreq-bench, which prints an error message for offline CPUs,
properly distinguish and report the zero and negative cases.
Fixes: ac5a181d065d ("cpupower: Add cpuidle parts into library") Fixes: 53d1cd6b125f ("cpupowerutils: bench - Fix cpu online check") Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
[carnil: Update/Refresh patch for 4.14.17: The issue with the
incorrect check has been fixed with upstream commit 53d1cd6b125f.
Keep in the patch the distinction and report for the zero and
negative cases.]
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name cpupower-fix-checks-for-cpu-existence.patch
Several functions in the libcpupower API are renamed or removed in
Linux 4.7. This is an backward-incompatible ABI change, so the
library soname should change from libcpupower.so.0 to
libcpupower.so.1.
Fixes: ac5a181d065d ("cpupower: Add cpuidle parts into library") Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name cpupower-bump-soname-version.patch
Ben Hutchings [Sun, 21 Feb 2016 15:33:15 +0000 (15:33 +0000)]
tools/build: Remove bpf() run-time check at build time
Forwarded: no
It is not correct to test that a syscall works on the build system's
kernel. We might be building on an earlier kernel version or with
security restrictions that block bpf().
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name tools-build-remove-bpf-run-time-check-at-build-time.patch
Ben Hutchings [Fri, 25 Sep 2015 19:09:23 +0000 (20:09 +0100)]
tools/perf: Remove shebang lines from perf scripts
Forwarded: no
perf scripts need to be invoked through perf, not directly through
perl (or other language interpreter). So including shebang lines in
them is useless and possibly misleading.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name tools-perf-remove-shebangs.patch
Ben Hutchings [Fri, 2 Dec 2016 23:06:18 +0000 (23:06 +0000)]
module: Disable matching missing version CRC
Forwarded: not-needed
This partly reverts commit cd3caefb4663e3811d37cc2afad3cce642d60061.
We want to fail closed if a symbol version CRC is missing, as the
alternative may allow subverting module signing.
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name module-disable-matching-missing-version-crc.patch
Ben Hutchings [Tue, 16 Feb 2016 02:45:42 +0000 (02:45 +0000)]
[i386/686-pae] PCI: Set pci=nobios by default
Forwarded: not-needed
CONFIG_PCI_GOBIOS results in physical addresses 640KB-1MB being mapped
W+X, which is undesirable for security reasons and will result in a
warning at boot now that we enable CONFIG_DEBUG_WX.
This can be overridden using the kernel parameter "pci=nobios", but we
want to disable W+X by default. Disable PCI BIOS probing by default;
it can still be enabled using "pci=bios".
Gbp-Pq: Topic debian
Gbp-Pq: Name i386-686-pae-pci-set-pci-nobios-by-default.patch
Luca Boccassi [Thu, 22 May 2025 18:32:07 +0000 (20:32 +0200)]
trust machine keyring (MoK) by default
Debian always trusted keys in MoK by default. Upstream made it conditional on
a new EFI variable being set. To keep backward compatibility skip this check.
Gbp-Pq: Topic features/all/db-mok-keyring
Gbp-Pq: Name trust-machine-keyring-by-default.patch
This allows a cert in DB to be used to sign modules,
in addition to certs in the MoK and built-in keyrings.
Signed-off-by: Robert Holmes <robeholmes@gmail.com> Signed-off-by: Jeremy Cline <jcline@redhat.com>
[bwh: Forward-ported to 5.19: adjust filename]
[наб: reinstate for 6.1, re-write description]
Gbp-Pq: Topic features/all/db-mok-keyring
Gbp-Pq: Name KEYS-Make-use-of-platform-keyring-for-module-signature.patch
This patch adds the logic for checking the kernel module's hash
base on blacklist. The hash must be generated by sha256 and enrolled
to dbx/mokx.
For example:
sha256sum sample.ko
mokutil --mokx --import-hash $HASH_RESULT
Whether the signature on ko file is stripped or not, the hash can be
compared by kernel.
Cc: David Howells <dhowells@redhat.com> Cc: Josh Boyer <jwboyer@fedoraproject.org> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: "Lee, Chun-Yi" <jlee@suse.com>
[Rebased by Luca Boccassi]
[bwh: Forward-ported to 5.19:
- The type parameter to is_hash_blacklisted() is now an enumeration
rather than a string
- Adjust filename, context]
Gbp-Pq: Topic features/all/db-mok-keyring
Gbp-Pq: Name 0003-MODSIGN-checking-the-blacklisted-hash-before-loading-a-kernel-module.patch
Linn Crosetto [Tue, 30 Aug 2016 17:54:38 +0000 (11:54 -0600)]
arm64: add kernel config option to lock down when in Secure Boot mode
Bug-Debian: https://bugs.debian.org/831827
Forwarded: no
Add a kernel configuration option to lock down the kernel, to restrict
userspace's ability to modify the running kernel when UEFI Secure Boot is
enabled. Based on the x86 patch by Matthew Garrett.
Determine the state of Secure Boot in the EFI stub and pass this to the
kernel using the FDT.
Signed-off-by: Linn Crosetto <linn@hpe.com>
[bwh: Forward-ported to 4.10: adjust context]
[Lukas Wunner: Forward-ported to 4.11: drop parts applied upstream]
[bwh: Forward-ported to 4.15 and lockdown patch set:
- Pass result of efi_get_secureboot() in stub through to
efi_set_secure_boot() in main kernel
- Use lockdown API and naming]
[bwh: Forward-ported to 4.19.3: adjust context in update_fdt()]
[dannf: Moved init_lockdown() call after uefi_init(), fixing SB detection]
[bwh: Drop call to init_lockdown(), as efi_set_secure_boot() now calls this]
[bwh: Forward-ported to 5.6: efi_get_secureboot() no longer takes a
sys_table parameter]
[bwh: Forward-ported to 5.7: EFI initialisation from FDT was rewritten, so:
- Add Secure Boot mode to the parameter enumeration in fdtparams.c
- Add a parameter to efi_get_fdt_params() to return the Secure Boot mode
- Since Xen does not have a property name defined for Secure Boot mode,
change efi_get_fdt_prop() to handle a missing property name by clearing
the output variable]
[Salvatore Bonaccorso: Forward-ported to 5.10: f30f242fb131 ("efi: Rename
arm-init to efi-init common for all arch") renamed arm-init.c to efi-init.c]
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name arm64-add-kernel-config-option-to-lock-down-when.patch
These drivers allow mapping arbitrary memory ranges as MTD devices.
This should be disabled to preserve the kernel's integrity when it is
locked down.
* Add the HWPARAM flag to the module parameters
* When slram is built-in, it uses __setup() to read kernel parameters,
so add an explicit check security_locked_down() check
Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Cc: Matthew Garrett <mjg59@google.com> Cc: David Howells <dhowells@redhat.com> Cc: Joern Engel <joern@lazybastard.org> Cc: linux-mtd@lists.infradead.org
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name mtd-disable-slram-and-phram-when-locked-down.patch
Ben Hutchings [Tue, 10 Sep 2019 10:54:28 +0000 (11:54 +0100)]
efi: Lock down the kernel if booted in secure boot mode
Based on an earlier patch by David Howells, who wrote the following
description:
> UEFI Secure Boot provides a mechanism for ensuring that the firmware will
> only load signed bootloaders and kernels. Certain use cases may also
> require that all kernel modules also be signed. Add a configuration option
> that to lock down the kernel - which includes requiring validly signed
> modules - if the kernel is secure-booted.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
[Salvatore Bonaccorso: After fixing https://bugs.debian.org/956197 the
help text for LOCK_DOWN_IN_EFI_SECURE_BOOT needs to be adjusted to
mention that lockdown is triggered in integrity mode] Signed-off-by: Salvatore Bonaccorso <carnil@debian.org>
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name efi-lock-down-the-kernel-if-booted-in-secure-boot-mo.patch
UEFI machines can be booted in Secure Boot mode. Add an EFI_SECURE_BOOT
flag that can be passed to efi_enabled() to find out whether secure boot is
enabled.
Move the switch-statement in x86's setup_arch() that inteprets the
secure_boot boot parameter to generic code and set the bit there.
Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
cc: linux-efi@vger.kernel.org
[rperier: Forward-ported to 5.5:
- Use pr_warn()
- Adjust context]
[bwh: Forward-ported to 5.6: adjust context]
[bwh: Forward-ported to 5.7:
- Use the next available bit in efi.flags
- Adjust context]
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name efi-add-an-efi_secure_boot-flag-to-indicate-secure-b.patch
The Marvell PHY was originally disabled because it can cause networking
failures on some systems. According to Lennert Buytenhek this is because some
of the variants added did not share the same register layout. Since the known
cases are all 4-ports disable those variants (indicated by a 4 in the
penultimate position of the model name) until they can be audited for
correctness.
[bwh: Also #if-out the init functions for these PHYs to avoid
compiler warnings]
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name disable-some-marvell-phys.patch
This patch adds the device tree for the "Model A" baseboard for
the SOQuartz CM4 SoM, which is not to be confused with the
Quartz64 Model A, which is the same form factor and SoC, but is
not a CM4 carrier board.
The board features a PCIe 2 x1 slot, USB 2 host ports, CSI/DSI
connectors, an eDP FFC connector, gigabit ethernet, HDMI, and a
12V DC barrel jack. Also present is a microSD card slot, 40-pin
GPIO, and a power and reset button.
Signed-off-by: Andrew Powers-Holmes <aholmes@omnom.net>
[rebase, misc fixes, reword] Signed-off-by: Nicolas Frattaroli <frattaroli.nicolas@gmail.com> Link: https://lore.kernel.org/r/20221116115337.541601-5-frattaroli.nicolas@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Gbp-Pq: Topic features/arm64/quartz64
Gbp-Pq: Name arm64-dts-rockchip-Add-SOQuartz-Model-A-baseboard.patch
The SOQuartz Model A base board is a carrier board for the CM4
form factor, designed around the PINE64 SOQuartz CM4 SoM.
The board sports "Model A" dimensions like the Quartz64 Model A,
but is not to be confused with that.
As for I/O, it features USB 2 ports, Gigabit Ethernet, a PCIe 2
x1 slot, HDMI, a 40-pin GPIO header, CSI/DSI connectors, an eDP
flat-flex cable connector, a 12V DC barrel jack for power input
and power/reset buttons as well as a microSD card slot.
Signed-off-by: Nicolas Frattaroli <frattaroli.nicolas@gmail.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20221116115337.541601-4-frattaroli.nicolas@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Gbp-Pq: Topic features/arm64/quartz64
Gbp-Pq: Name dt-bindings-arm-rockchip-Add-SOQuartz-Model-A.patch
This adds a device tree for the PINE64 SOQuartz blade baseboard,
a 1U rack mountable baseboard for the CM4 form factor with PoE
support designed for the SOQuartz CM4 System-on-Module.
The board takes power from either PoE or a 5V DC input, and allows
for mounting an M.2 SSD.
The board also features one USB 2.0 host port, one HDMI output,
a 3.5mm jack for UART, and the aforementioned gigabit networking
port.
Signed-off-by: Andrew Powers-Holmes <aholmes@omnom.net>
[rebase, squash, reword, misc fixes] Signed-off-by: Nicolas Frattaroli <frattaroli.nicolas@gmail.com> Link: https://lore.kernel.org/r/20221116115337.541601-3-frattaroli.nicolas@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Gbp-Pq: Topic features/arm64/quartz64
Gbp-Pq: Name arm64-dts-rockchip-Add-SOQuartz-blade-board.patch
Add a compatible for the SOQuartz Blade base board to the rockchip
platforms binding.
The SOQuartz Blade is a PoE-capable carrier board for the CM4 SoM
form factor, designed around the SOQuartz CM4 System-on-Module.
The board features the usual connectivity (GPIO, USB, HDMI,
Ethernet) and an M.2 slot for SSDs. It may also be powered from
a 5V barrel jack input, and has a 3.5mm jack for UART debug
output.
Signed-off-by: Nicolas Frattaroli <frattaroli.nicolas@gmail.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20221116115337.541601-2-frattaroli.nicolas@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Gbp-Pq: Topic features/arm64/quartz64
Gbp-Pq: Name dt-bindings-arm-rockchip-Add-SOQuartz-Blade.patch
This patch enables the PCIe2 on the CM4IO board when paired with
a SOQuartz CM4 System-on-Module board. combphy2 also needs to be
enabled in this case to make the PHY work for this.
Enabling x32 in the standard amd64 kernel would increase its attack
surface while provide no benefit to the vast majority of its users.
No-one seems interested in regularly checking for vulnerabilities
specific to x32 (at least no-one with a white hat).
Still, adding another flavour just to turn on x32 seems wasteful. And
the only differences on syscall entry are a few instructions that mask
out the x32 flag and compare the syscall number.
Use a static key to control whether x32 syscalls are really enabled, a
Kconfig parameter to set its default value and a kernel parameter
"syscall.x32" to change it at boot time.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic features/x86
Gbp-Pq: Name x86-make-x32-syscall-support-conditional.patch
Since this is not a particularly thorough test, if we find any bad
bits of RAM then there is a fair chance that there are other bad bits
we fail to detect.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic features/x86
Gbp-Pq: Name x86-memtest-WARN-if-bad-RAM-found.patch
The Rockchip RK3568 has two USB XHCI controllers. The USB 2.0 signals
are connected to a PHY providing one host-only port and one OTG port.
The USB 3.0 signals are connected to two USB3.0/PCIE/SATA combo PHY.
The ODROID M1 has 2 type A USB 3.0 connectors, with the USB 3.0 signals
connected to the two combo PHYs. For the USB 2.0 signals, one connector
is connected to the host-only PHY and uses the same power switch as the
USB 2.0 ports. The other connector has its own power switch and is
connected to the OTG PHY, which is also connected to a device only
micro-USB connector. The purpose of this micro-USB connector is for
firmware update using the Rockusb vendor specific USB class. Therefore
it does not make sense to enable this port on Linux, and the PHY is
forced to host mode.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net> Tested-by: Dan Johansen <strit@manjaro.org> Link: https://lore.kernel.org/r/20220930051246.391614-11-aurelien@aurel32.net Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Gbp-Pq: Topic features/arm64
Gbp-Pq: Name arm64-dts-rockchip-Enable-the-USB-3.0-ports-on-ODROI.patch
The Rockchip RK3568 has two USB OHCI/EHCI controllers connected to a PHY
providing one host-only port and one OTG port. On the ODROID-M1, they
are both used in host mode. The USB ports are powered by a DC/DC
converter providing 5V and named VCC5V0_SYS on the schematics, followed
by a power switch.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net> Tested-by: Dan Johansen <strit@manjaro.org> Link: https://lore.kernel.org/r/20220930051246.391614-10-aurelien@aurel32.net Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Gbp-Pq: Topic features/arm64
Gbp-Pq: Name arm64-dts-rockchip-Enable-the-USB-2.0-ports-on-ODROI.patch
On the ODROID-M1, the I2S1 TDM controller is connected to the rk809
codec in I2S mode. It is used to provide a stereo headphones output and
a mono speaker output. A GPIO with an external pullup is used as an
headphone detection input.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net> Tested-by: Dan Johansen <strit@manjaro.org> Link: https://lore.kernel.org/r/20220930051246.391614-6-aurelien@aurel32.net Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Gbp-Pq: Topic features/arm64
Gbp-Pq: Name arm64-dts-rockchip-Add-analog-audio-on-ODROID-M1.patch
Enable the Rockchip Serial Flash Controller for the ODROID-M1 and add
the corresponding SPI NOR flash entry. The SFC is used in dual I/O mode
and not quad I/O mode, as the FSPI_D2 pin is shared with the EMMC_RSTn
pin.
The partitions addresses and sizes are taken from the ODROID-M1
Partition Table page on the ODROID wiki.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net> Tested-by: Dan Johansen <strit@manjaro.org> Link: https://lore.kernel.org/r/20220930051246.391614-5-aurelien@aurel32.net Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Gbp-Pq: Topic features/arm64
Gbp-Pq: Name arm64-dts-rockchip-Add-NOR-flash-to-ODROID-M1.patch
This patch is to add a device tree for new board Hardkernel ODROID-M1
based on Rockchip RK3568, includes basic peripherals -
uart/eMMC/uSD/i2c and on-board ethernet.
Signed-off-by: Dongjin Kim <tobetter@gmail.com>
[aurelien@aurel32.net: addressed issues from initial review] Signed-off-by: Aurelien Jarno <aurelien@aurel32.net> Tested-by: Dan Johansen <strit@manjaro.org> Link: https://lore.kernel.org/r/20220930051246.391614-3-aurelien@aurel32.net Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Gbp-Pq: Topic features/arm64
Gbp-Pq: Name arm64-dts-rockchip-Add-Hardkernel-ODROID-M1-board.patch
Now that modpost extracts symbol versions from *.cmd files, it can't
find the versions for these 4 symbols. This is due to the way we link
their objects together ahead of the full vmlinux link. genksyms puts
their symbol CRCs in .str{,n}{cat,cpy}.o.cmd, but modpost only reads
the .sty{,n}cpy.o.cmd files.
Add assembly sources that bring the appropriate routines together with
include directives instead of using the linker for this.
Reported-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Fixes: f292d875d0dc ("modpost: extract symbol versions from *.cmd files") Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/alpha
Gbp-Pq: Name alpha-fix-missing-symbol-versions-for-str-n-cat-cpy.patch
Adds a new ACPI init routine acpi_fixup_m400_quirks that adds
a work-around for HPE ProLiant m400 APEI firmware problems.
The work-around disables APEI when CONFIG_ACPI_APEI is set and
m400 firmware is detected. Without this fixup m400 systems
experience errors like these on startup:
After commit faa16bc404d7 ("lib: Use existing define with
polynomial") the lib/xz/xz_crc32.c includes a header from include/linux
directory thus any other user of this code should define proper include
path.
This fixes the build error on powerpc with CONFIG_KERNEL_XZ:
In file included from ../arch/powerpc/boot/../../../lib/decompress_unxz.c:233:0,
from ../arch/powerpc/boot/decompress.c:42:
../arch/powerpc/boot/../../../lib/xz/xz_crc32.c:18:29: fatal error: linux/crc32poly.h: No such file or directory
Reported-by: Michal Kubecek <mkubecek@suse.cz> Fixes: faa16bc404d7 ("lib: Use existing define with polynomial") Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Reported-by: kbuild test robot <lkp@intel.com> Reported-by: Meelis Roos <mroos@linux.ee> Tested-by: Michal Kubecek <mkubecek@suse.cz>
Gbp-Pq: Topic bugfix/powerpc
Gbp-Pq: Name powerpc-boot-fix-missing-crc32poly.h-when-building-with-kernel_xz.patch
The xen-privcmd driver, which can be modular, calls set_pte_at()
which in turn may call __sync_icache_dcache().
The call to __sync_icache_dcache() may be optimised out because it is
conditional on !pte_special(), and xen-privcmd calls pte_mkspecial().
However, in a non-LPAE configuration there is no "special" bit and the
call is really unconditional.
Fixes: 3ad0876554ca ("xen/privcmd: add IOCTL_PRIVCMD_MMAP_RESOURCE") Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/arm
Gbp-Pq: Name arm-mm-export-__sync_icache_dcache-for-xen-privcmd.patch
Ben Hutchings [Sun, 6 Feb 2022 23:00:26 +0000 (00:00 +0100)]
sh: Do not use hyphen in exported variable names
arch/sh/Makefile defines and exports ld-bfd to be used by
arch/sh/boot/Makefile and arch/sh/boot/compressed/Makefile. However
some shells, including dash, will not pass through environment
variables whose name includes a hyphen. Usually GNU make does not use
a shell to recurse, but if e.g. $(srctree) contains '~' it will use a
shell here.
Rename the variable to ld_bfd.
(Another instance of this problem was fixed upstream by commit 82977af93a0d "sh: rename suffix-y to suffix_y".)
References: https://buildd.debian.org/status/fetch.php?pkg=linux&arch=sh4&ver=4.13%7Erc5-1%7Eexp1&stamp=1502943967&raw=0 Fixes: ef9b542fce00 ("sh: bzip2/lzma uImage support.") Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/sh
Gbp-Pq: Name sh-boot-do-not-use-hyphen-in-exported-variable-name.patch
Ben Hutchings [Sat, 22 Jul 2017 16:37:33 +0000 (17:37 +0100)]
perf tools: Fix unwind build on i386
Forwarded: no
EINVAL may not be defined when building unwind-libunwind.c with
REMOTE_UNWIND_LIBUNWIND, resulting in a compiler error in
LIBUNWIND__ARCH_REG_ID(). Its only caller, access_reg(), only checks
for a negative return value and doesn't care what it is. So change
-EINVAL to -1.
Fixes: 52ffe0ff02fc ("Support x86(32-bit) cross platform callchain unwind.") Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name perf-tools-fix-unwind-build-on-i386.patch
The old board code for the TS419 assigns MPP pins 15 and 16 as SATA
activity signals (and none as SATA presence signals). Currently the
device tree assigns the SoC's default pinmux groups for SATA, which
conflict with the second Ethernet port.
Reported-by: gmbh@gazeta.pl Tested-by: gmbh@gazeta.pl
References: https://bugs.debian.org/855017 Cc: stable@vger.kernel.org # 3.15+ Fixes: 934b524b3f49 ("ARM: Kirkwood: Add DT description of QNAP 419") Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/arm
Gbp-Pq: Name arm-dts-kirkwood-fix-sata-pinmux-ing-for-ts419.patch
Too many people come complaining about losing their data -- and indeed,
there's no warning outside a wiki and the mailing list tribal knowledge.
Message severity chosen for consistency with XFS -- "alert" makes dmesg
produce nice red background which should get the point across.
Signed-off-by: Adam Borowski <kilobyte@angband.pl>
[bwh: Also add_taint() so this is flagged in bug reports]
Gbp-Pq: Topic debian
Gbp-Pq: Name btrfs-warn-about-raid5-6-being-experimental-at-mount.patch
Ben Hutchings [Wed, 13 Jul 2016 00:37:22 +0000 (01:37 +0100)]
fanotify: Taint on use of FANOTIFY_ACCESS_PERMISSIONS
Forwarded: not-needed
Various free and proprietary AV products use this feature and users
apparently want it. But punting access checks to userland seems like
an easy way to deadlock the system, and there will be nothing we can
do about that. So warn and taint the kernel if this feature is
actually used.
Gbp-Pq: Topic debian
Gbp-Pq: Name fanotify-taint-on-use-of-fanotify_access_permissions.patch
Ben Hutchings [Sat, 18 Mar 2017 20:47:58 +0000 (20:47 +0000)]
fjes: Disable auto-loading
Bug-Debian: https://bugs.debian.org/853976
Forwarded: no
fjes matches a generic ACPI device ID, and relies on its probe
function to distinguish whether that really corresponds to a supported
device. Very few system will need the driver and it wastes memory on
all the other systems where the same device ID appears, so disable
auto-loading.
Gbp-Pq: Topic debian
Gbp-Pq: Name fjes-disable-autoload.patch
Ben Hutchings [Sat, 20 Apr 2013 14:52:02 +0000 (15:52 +0100)]
viafb: Autoload on OLPC XO 1.5 only
Bug-Debian: https://bugs.debian.org/705788
Forwarded: no
It appears that viafb won't work automatically on all the boards for
which it has a PCI device ID match. Currently, it is blacklisted by
udev along with most other framebuffer drivers, so this doesn't matter
much.
However, this driver is required for console support on the XO 1.5.
We need to allow it to be autoloaded on this model only, and then
un-blacklist it in udev.
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name viafb-autoload-on-olpc-xo1.5-only.patch
There are two drivers claiming the platform:pcspkr device:
- pcspkr creates an input(!) device that can only beep
- snd-pcsp creates an equivalent input device plus a PCM device that can
play barely recognisable renditions of sampled sound
snd-pcsp is blacklisted by the alsa-base package, but not everyone
installs that. On PCs where no sound is wanted at all, both drivers
will still be loaded and one or other will complain that it couldn't
claim the relevant I/O range.
In case anyone finds snd-pcsp useful, we continue to build it. But
remove the alias, to ensure it's not loaded where it's not wanted.
Gbp-Pq: Topic debian
Gbp-Pq: Name snd-pcsp-disable-autoload.patch
Ben Hutchings [Sun, 31 Mar 2013 02:58:04 +0000 (03:58 +0100)]
cdc_ncm,cdc_mbim: Use NCM by default
Forwarded: not-needed
Devices that support both NCM and MBIM modes should be kept in NCM
mode unless there is userland support for MBIM.
Set the default value of cdc_ncm.prefer_mbim to false and leave it to
userland (modem-manager) to override this with a modprobe.conf file
once it's ready to speak MBIM.
Gbp-Pq: Topic debian
Gbp-Pq: Name cdc_ncm-cdc_mbim-use-ncm-by-default.patch
There is still laptop firmware that touches the integrated GPU behind
the operating system's back, and doesn't say so in the RMRR table.
Enabling the IOMMU for all devices causes breakage.
Replace CONFIG_INTEL_IOMMU_DEFAULT_ON with a 3-way choice
corresponding to "on", "off", and "on,intgpu_off".
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic features/x86
Gbp-Pq: Name intel-iommu-add-kconfig-option-to-exclude-igpu-by-default.patch
There is still laptop firmware that touches the integrated GPU behind
the operating system's back, and doesn't say so in the RMRR table.
Enabling the IOMMU for all devices causes breakage, but turning it off
for all graphics devices seems like a major weakness.
Add an option, intel_iommu=intgpu_off, to exclude only integrated GPUs
from remapping. This is a narrower exclusion than igfx_off: it only
affects Intel devices on the root bus. Devices attached through an
external port (Thunderbolt or ExpressCard) won't be on the root bus.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic features/x86
Gbp-Pq: Name intel-iommu-add-option-to-exclude-integrated-gpu-only.patch
Ben Hutchings [Mon, 11 Jan 2016 15:23:55 +0000 (15:23 +0000)]
security,perf: Allow further restriction of perf_event_open
Forwarded: https://lkml.org/lkml/2016/1/11/587
When kernel.perf_event_open is set to 3 (or greater), disallow all
access to performance events by users without CAP_SYS_ADMIN.
Add a Kconfig symbol CONFIG_SECURITY_PERF_EVENTS_RESTRICT that
makes this value the default.
This is based on a similar feature in grsecurity
(CONFIG_GRKERNSEC_PERF_HARDEN). This version doesn't include making
the variable read-only. It also allows enabling further restriction
at run-time regardless of whether the default is changed.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic features/all
Gbp-Pq: Name security-perf-allow-further-restriction-of-perf_event_open.patch
add sysctl to disallow unprivileged CLONE_NEWUSER by default
This is a short-term patch. Unprivileged use of CLONE_NEWUSER
is certainly an intended feature of user namespaces. However
for at least saucy we want to make sure that, if any security
issues are found, we have a fail-safe.
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
[bwh: Remove unneeded binary sysctl bits]
[bwh: Keep this sysctl, but change the default to enabled]
Gbp-Pq: Topic debian
Gbp-Pq: Name add-sysctl-to-disallow-unprivileged-CLONE_NEWUSER-by-default.patch
Ben Hutchings [Sun, 4 Aug 2019 23:29:11 +0000 (00:29 +0100)]
hamradio: Disable auto-loading as mitigation against local exploits
Forwarded: not-needed
We can mitigate the effect of vulnerabilities in obscure protocols by
preventing unprivileged users from loading the modules, so that they
are only exploitable on systems where the administrator has chosen to
load the protocol.
The 'ham' radio protocols (ax25, netrom, rose) are not actively
maintained or widely used. Therefore disable auto-loading.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic debian
Gbp-Pq: Name hamradio-disable-auto-loading-as-mitigation-against-local-exploits.patch
Ben Hutchings [Thu, 16 Feb 2017 19:09:17 +0000 (19:09 +0000)]
dccp: Disable auto-loading as mitigation against local exploits
Forwarded: not-needed
We can mitigate the effect of vulnerabilities in obscure protocols by
preventing unprivileged users from loading the modules, so that they
are only exploitable on systems where the administrator has chosen to
load the protocol.
The 'dccp' protocol is not actively maintained or widely used.
Therefore disable auto-loading.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic debian
Gbp-Pq: Name dccp-disable-auto-loading-as-mitigation-against-local-exploits.patch
Ben Hutchings [Fri, 19 Nov 2010 02:12:48 +0000 (02:12 +0000)]
[PATCH 1/3] rds: Disable auto-loading as mitigation against local exploits
Forwarded: not-needed
Recent review has revealed several bugs in obscure protocol
implementations that can be exploited by local users for denial of
service or privilege escalation. We can mitigate the effect of any
remaining vulnerabilities in such protocols by preventing unprivileged
users from loading the modules, so that they are only exploitable on
systems where the administrator has chosen to load the protocol.
The 'rds' protocol is one such protocol that has been found to be
vulnerable, and which was not present in the 'lenny' kernel.
Therefore disable auto-loading.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic debian
Gbp-Pq: Name rds-Disable-auto-loading-as-mitigation-against-local.patch
Ben Hutchings [Fri, 19 Nov 2010 02:12:48 +0000 (02:12 +0000)]
[PATCH 2/3] af_802154: Disable auto-loading as mitigation against local exploits
Forwarded: not-needed
Recent review has revealed several bugs in obscure protocol
implementations that can be exploited by local users for denial of
service or privilege escalation. We can mitigate the effect of any
remaining vulnerabilities in such protocols by preventing unprivileged
users from loading the modules, so that they are only exploitable on
systems where the administrator has chosen to load the protocol.
The 'af_802154' (IEEE 802.15.4) protocol is not widely used, was
not present in the 'lenny' kernel, and seems to receive only sporadic
maintenance. Therefore disable auto-loading.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic debian
Gbp-Pq: Name af_802154-Disable-auto-loading-as-mitigation-against.patch
Add the '-@' DTC option for the Raspberry Pi devices. This option
populates the '__symbols__' node that contains all the necessary symbols
for supporting device-tree overlays (for instance from the firmware or
the bootloader) on these devices.
The Rasbperry Pi devices are well known for their GPIO header, that
allow various "HATs" or other modules do be connected and this enables
users to create out-of-tree device-tree overlays for these modules.
Please note that this change does increase the size of the resulting DTB
by ~40%. For example, with v6.4-rc1 increase in size is as follows:
If firmware loading fails due to a missing file, log a second error
message referring to our wiki page about firmware. This will explain
why some firmware is in non-free, or can't be packaged at all. Only
do this once per boot.
Do something similar in the radeon and amdgpu drivers, where we have
an early check to avoid failing at a point where we cannot display
anything.
Gbp-Pq: Topic debian
Gbp-Pq: Name firmware_class-refer-to-debian-wiki-firmware-page.patch
radeon requires firmware/microcode for the GPU in all chips, but for
newer chips (apparently R600 'Evergreen' onward) it also expects
firmware for the memory controller and other sub-blocks.
radeon attempts to gracefully fall back and disable some features if
the firmware is not available, but becomes unstable - the framebuffer
and/or system memory may be corrupted, or the display may stay black.
Therefore, perform a basic check for the existence of
/lib/firmware/{radeon,amdgpu} when a device is probed, and abort if it
is missing, except for the pre-R600 case.
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name radeon-amdgpu-firmware-is-required-for-drm-and-kms-on-r600-onward.patch
Ben Hutchings [Sun, 9 Dec 2012 16:02:00 +0000 (16:02 +0000)]
firmware_class: Log every success and failure against given device
Forwarded: no
The hundreds of users of request_firmware() have nearly as many
different log formats for reporting failures. They also have only the
vaguest hint as to what went wrong; only firmware_class really knows
that. Therefore, add specific log messages for the failure modes that
aren't currently logged.
In case of a driver that tries multiple names, this may result in the
impression that it failed to initialise. Therefore, also log successes.
This makes many error messages in drivers redundant, which will be
removed in later patches.
This does not cover the case where we fall back to a user-mode helper
(which is no longer enabled in Debian).
NOTE: hw-detect will depend on the "firmware: failed to load %s (%d)\n"
format to detect missing firmware.
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name firmware_class-log-every-success-and-failure.patch
The iwlwifi driver currently supports firmware API versions 4-6 for
these devices. It will request the file for the latest supported
version and then fall back to earlier versions. However, the latest
version that has actually been released is 4, so we expect the
requests for versions 6 and then 5 to fail.
The installer appears to report any failed request, and it is probably
not easy to detect that this particular failure is harmless. So stop
requesting the unreleased firmware.
Gbp-Pq: Topic debian
Gbp-Pq: Name iwlwifi-do-not-request-unreleased-firmware.patch
Ben Hutchings [Mon, 24 Aug 2009 22:19:58 +0000 (23:19 +0100)]
af9005: Use request_firmware() to load register init script
Forwarded: no
Read the register init script from the Windows driver. This is sick
but should avoid the potential copyright infringement in distributing
a version of the script which is directly derived from the driver.
Gbp-Pq: Topic features/all
Gbp-Pq: Name drivers-media-dvb-usb-af9005-request_firmware.patch
The top-level Makefile warns if the compiler version string changes at
all between the kernel build and an out-of-tree module build.
We expect that major compiler version changes could introduce ABI
changes, and override the CC variable in out-of-tree module builds to
ensure that the same major compiler version is used. But minor
version changes should not make a difference, so this exact version
comparison produces false warnings.
Since custom kernel packages don't have that, don't remove the version
comparison. Instead, skip it if $(DEBIAN_KERNEL_NO_CC_VERSION_CHECK)
is non-empty.
Gbp-Pq: Topic debian
Gbp-Pq: Name makefile-make-compiler-version-comparison-optional.patch
Ben Hutchings [Fri, 13 May 2022 19:08:08 +0000 (21:08 +0200)]
module: Avoid ABI changes when debug info is disabled
Forwarded: not-needed
CI builds are done with debug info disabled, but this removes some
members from struct module. This causes builds to fail if there is an
ABI reference for the current ABI.
Define these members unconditionally, so that there is no ABI change.
Gbp-Pq: Topic debian
Gbp-Pq: Name module-avoid-abi-changes-when-debug-info-is-disabled.patch
DKMS and module-assistant both build OOT modules as root. If they
build an old OOT module that still use SUBDIRS this causes Kbuild
to try building a full kernel, which obviously fails but not before
deleting files from the installed headers package.
To avoid such mishaps, detect this situation and abort the build.
The error message is based on that used in commit 0126be38d988
"kbuild: announce removal of SUBDIRS if used".
Gbp-Pq: Topic debian
Gbp-Pq: Name kbuild-abort-build-if-subdirs-used.patch
The module.lds linker script is now built under the scripts directory,
where previously it was under arch/$(SRCARCH).
However, we package the scripts directory as linux-kbuild, which is
meant to be able to do support native and cross-builds. That means it
shouldn't contain files for a specific target architecture without a
wrapper to select between them, and it doesn't appear that linker
scripts are powerful enough to implement such a wrapper.
Building module.lds in a different location would require relatively
large changes. Moving it in the package build rules can work, but we
need to support custom kernel builds from the same source so we can't
assume it's moved.
Therefore, we move module.lds under the arch build directory in
rules.real and change Makefile.modfinal to look for it in both places.
Gbp-Pq: Topic debian
Gbp-Pq: Name kbuild-look-for-module.lds-under-arch-directory-too.patch
projects / linux.git / log